Internet Engineering Task Force (IETF) T. Tsenov 


Request for Comments: 5972 H. Tschofenig 
Category: Informational Nokia Siemens Network 
ISSN: 2070-1721 X. Fu, Ed. 
Univ. Goettingen 

C. Aoun 

Consultant 


E. Davies 
Folly Consulting 
October 2010 


General Internet Signaling Transport (GIST) State Machine 
Abstract 
This document describes state machines for the General Internet 
Signaling Transport (GIST). The states of GIST nodes for a given 
flow and their transitions are presented in order to illustrate how 
GIST may be implemented. 
Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5972. 


Copyright Notice 


Copyright (c) 2010 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
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include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may 
not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 
than English. 
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Les 


Introduction 


The state machines described in this document are illustrative of how 
the GIST protocol defined in [1] may be implemented for the GIST 
nodes in different locations of a flow path. Where there are 
differences, [1] is authoritative. The state machines are 
informative only. Implementations may achieve the same results using 
different methods. 


There are two types of possible entities for GIST signaling: 


- GIST querying node: GIST node that initiates the discovery of the 
next peer; 


- GIST responding node: GIST node that is the discovered next peer. 


We describe a set of state machines for these entities to illustrate 
how GIST may be implemented. 


Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [2]. 


Notational Conventions Used in State Diagrams 


The following text is reused from [3], and the state diagrams are 
based on the conventions specified in [4], Section 8.2.1. Additional 
state machine details are taken from [5]. 


RFC 4137 [3] reproduced the following text from Section 8.2.1 of IEEE 
802-1X-2004 [4]. 


State diagrams are used to represent the operation of the protocol 
by a number of cooperating state machines, each comprising a group 
of connected, mutually exclusive states. Only one state of each 
machine can be active at any given time. 


All permissible transitions between states are represented by 
arrows, the arrowhead denoting the direction of the possible 
transition. Labels attached to arrows denote the condition(s) 
that must be met in order for the transition to take place. All 
conditions are expressions that evaluate to TRUE or FALSE; if a 
condition evaluates to TRUE, then the condition is met. The label 
UCT denotes an unconditional transition (i.e., UCT always 
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evaluates to TRUE). A transition that is global in nature (i.e., 
a transition that occurs from any of the possible states if the 
condition attached to the arrow is met) is denoted by an open 
arrow; i.e., no specific state is identified as the origin of the 
transition. When the condition associated with a global 
transition is met, it supersedes all other exit conditions 
including UCT. The special global condition BEGIN supersedes all 
other global conditions, and once asserted it remains asserted 
until all state blocks have executed to the point that variable 
assignments and other consequences of their execution remain 
unchanged. 


On entry to a state, the procedures defined for the state (if any) 
are executed exactly once, in the order that they appear on the 
page. Each action is deemed to be atomic; i.e., execution of a 
procedure completes before the next sequential procedure starts to 
execute. No procedures execute outside a state block. The 
procedures in only one state block execute at a time, even if the 
conditions for execution of state blocks in different state 
machines are satisfied, and all procedures in an executing state 
block complete execution before the transition to and execution of 
any other state block occurs. That is, the execution of any state 
block appears to be atomic with respect to the execution of any 
other state block, and the transition condition to that state from 
the previous state is TRUE when execution commences. The order of 
execution of state blocks in different state machines is undefined 
except as constrained by their transition conditions. A variable 
that is set to a particular value in a state block retains this 
value until a subsequent state block executes a procedure that 
modifies the value. 


On completion of all the procedures within a state, all exit 
conditions for the state (including all conditions associated with 
global transitions) are evaluated continuously until one of the 
conditions is met. The label ELSE denotes a transition that 
occurs if none of the other conditions for transitions from the 
state are met (i.e., ELSE evaluates to TRUE if all other possible 
exit conditions from the state evaluate to FALSE). Where two or 
more exit conditions with the same level of precedence become TRUE 
simultaneously, the choice as to which exit condition causes the 
state transition to take place is arbitrary. 


In addition to the above notation, there are a couple of 
clarifications specific to this document. First, all boolean 
variables are initialized to FALSE before the state machine execution 
begins. Second, the following notational shorthand is specific to 
this document: 
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<variable> = <expression1> | <expression2> | 


Execution of a statement of this form will result in <variable> 
having a value of exactly one of the expressions. The logic for 
which of those expressions gets executed is outside of the state 
machine and could be environmental, configurable, or based on 
another state machine such as that of the method. 


4. State Machine Symbols 


€ € 


TÉ 


{ 


) 
Used to force the precedence of operators in boolean expressions 
and to delimit the argument(s) of actions within state boxes. 


Used as a terminating delimiter for actions within state boxes. 
Where a state box contains multiple actions, the order of 
execution follows the normal English language conventions for 
reading text. 


Assignment action. The value of the expression to the right of 
the operator is assigned to the variable to the left of the 
operator. Where this operator is used to define multiple 
assignments, e.g., a = b = X, the action causes the value of the 
expression following the right-most assignment operator to be 
assigned to all of the variables that appear to the left of the 
right-most assignment operator. 


Logical NOT operator. 


Logical AND operator. 

Logical OR operator. 

.. then... 

Conditional action. If the boolean expression following the "if" 
evaluates to TRUE, then the action following the "then" is 
executed. 

statement 1, ... statement N } 


Compound statement. Braces are used to group statements that are 
executed together as if they were a single statement. 


Tsenov, et al. Informational [Page 5] 


RFC 5972 GIST State Machine October 2010 


Inequality. Evaluates to TRUE if the expression to the left of 
the operator is not equal in value to the expression to the right. 


Equality. Evaluates to TRUE if the expression to the left of the 
operator is equal in value to the expression to the right. 


> 
Greater than. Evaluates to TRUE if the value of the expression to 
the left of the operator is greater than the value of the 
expression to the right. 

<= 
Less than or equal to. Evaluates to TRUE if the value of the 
expression to the left of the operator is either less than or 
equal to the value of the expression to the right. 

++ 
Increment the preceding integer operator by 1. 

+ 
Arithmetic addition operator. 

& 
Bitwise AND operator. 

5. Common Rules 


Throughout the document we use terms defined in [1], such as Query, 
Response, and Confirm. 


The state machine represents the handling of GIST messages that match 
a Message Routing State’s Message Routing Information (MRI), NSIS 
Signaling Layer Protocol identifier (NSLPID), and session identifier 
(SID) and with no protocol errors. Separate parallel instances of 
the state machines should handle messages for different Message 
Routing States (MRSs). 


The state machine represents the states and transitions of the 
upstream and downstream peers of the Message Routing State. 


For simplification, not all objects included in a message are shown. 
Only those that are significant for the case are shown. State 
machines do not present handling of messages that are not significant 
for management of the states. 
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5e 


t; 


The state machines presented in this document do not cover all 
functions of a GIST node. Functionality of message forwarding, 
transmission of NSLP data without MRS establishment, and providing of 
the received messages to the appropriate MRS, we refer to as "lower- 
level pre-processing" step. Pre-processing provides to the 
appropriate MRS state machine only the messages that are matched 
against waiting Query/Response cookies, or the triplet (MRI, NSLPID, 
SID) of the established MRS. This is represented by "rx_*" events in 
the state machines. 


Management of messaging associations (MAs) is considered in the 
document via procedures, events, and variables, which describe MA 
interaction with the MRS state machines. A state machine for MA 
management is not explicitly presented. 


Common Procedures 


Tx_Query: 
Transmit of Query message. 


Tx_Response: 
Transmit of Response message. 


Tx_Confirm: 
Transmit of Confirm message. 


Tx_Data: 
Transmit of Data message. 


Tg_MessageStatus: 
NSLP/GIST API message informing NSLP application of unsuccessful 
delivery of a message 


Tg_RecvMsg: 
NSLP/GIST API message that provides received message to NSLP 
application. 


Tg_NetworkNotification: 
NSLP/GIST API message that informs NSLP application of change in 
MRS. 


Install downstream/upstream MRS: 
Install new Message Routing State and save the corresponding peer 
state info (IP address and UDP port, or pointer to the used MA) 
for the current Message Routing State or update the corresponding 
peer state info. 
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Delete MRS: 
Delete installed downstream/upstream peer's info for the current 
Message Routing State, and delete the Message Routing State if 
required. 


Refresh MRS: 
Refreshes installed MRS. 


Queue NSLP info: 
Save NSLP messages in a queue until conditions for their sending 
are present, e.g., a required MA association is established. 


CheckPeerInfo: 
The sender of the received data message is matched against the 
installed peer info in the MRS. 


Delete MA: 
Delete/disconnect used MA. 


Stop using shared MA: 
Stop using shared MA. If the shared MA is no longer being used by 
any other MRSs, it depends on the local policy whether it is 
deleted or kept. 


Tg_Establish_MA: 
Triggers establishment of a new MA. 


Start/Restart a timer variable (Section 5.3): 
Start/Restart of a certain timer. 


Install/Update/Delete UpstreamPeerInfo variable (Section 5.3): 
Management of upstream peer info in state machine of responding 
node. 


5.2. Common Events 


Rx_Query: 
Receive of Query message. 


Rx_Response: 
Receive of Response message. 


Rx_Confirm: 
Receive of Confirm message. 


Rx_Data: 
Receive of Data message. 
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Tg_SendMsg: 
NSLP/GIST API message from NSLP application that requests 
transmission of a NSLP message. 


Tg_SetStateLifetime (time_period) : 
NSLP/GIST API message providing info for the lifetime of a Routing 
State (RS), required by the application. "Time_period = 0" 
represents the cancellation of established RSs/MAs, invoked by the 
NSLP application. 


Tg_InvalidRoutingState: 
NSLP/GIST API notification from NSLP application for path change. 


Tg_ERROR: 
General Error event / system level error. 


Tg_MA _Established: 
A new MA has been successfully established. 


Tg_MA_ Error: 
Error event with used MA. 


Timeout a timer variable (Section 5.3): 
Timeout of a certain timer. 


5.3. Common Variables 
Variables listed in this section are defined as: 
- Specific information carried in the received messages. 


- Conditions that are results of processes not defined in the state 
machine model. 


State machine logic is based on these general conditions and message 
parameters. 


The type of mode and destination info is determined by NSLP 
application parameters and local GIST policy. Here it is represented 
by the common variables D-mode, C-mode, and MAinfo. 


C-mode: 
The message MUST be transmitted in C-mode. This is specified by 
"Message transfer attributes" set by NSLP application to any of 
the following values: 


"Reliability" is set to TRUE. 
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"Security" is set to values that request secure handling of a 
message. 


"Local processing" is set to values that require services offered 


by C-mode (e.g., congestion control) [1]. 

D-mode: 
The message MUST be transmitted in D-mode. This is specified by 
local policy rules. If the "Message transfer attributes" are not 


set by NSLP application to any of the following values, then: 
"Reliability" is set to TRUE. 


"Security" is set to values that request special security handling 
of a message. 


"Local processing" is set to values that require services offered 
by C-mode [1]. 


MAinfo: 
GIST message parameters describing the required MA or proposed MA, 
e.g., "Stack-proposal" and "Stack-Configuration-Data" [1]. 


NSLPdata: 
NSLP application data. 


RespCookie: 
Responder Cookie that is being sent by the responding node with 
the Response message in case that its local policy requires a 
confirmation from the querying node. 


ConfirmRequired: 
Indicator that a Confirm message is required by the local policy 
rule for installation of a new MRS. 


NewPeer: 
Indicator that a Response message is received from a new 
responding peer. 


MAexist: 
Indicator that an existing MA will be reused in data transfer 


between peers. 


UpstreamPeerInfo: 
Upstream peer info that is saved in an established MRS. 


T_Inactive_QNode: 
Message Routing State lifetime timer in querying node. 
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T_Expired_RNode: 
Message Routing State lifetime timer in responding node. 


T_Refresh_QNode: 
Message Routing State refresh timer in querying node. 


T_No_Response: 
Timer for the waiting period for Response message in querying 
node. 


T_No_Confirm: 
Timer for the waiting period for Confirm message in responding 
node. 


No_MRS_Installed: 
Data sent by responding node via a Response message that indicates 
loss of Confirm message. 


6. State Machines 


The following section presents the state machine diagrams of GIST 
peers. RFC 5972 is published as a .txt file. A supplementary .pdf 
is being published as well. 


In the .pdf document, the state machine diagrams are depicted in 
detail. All state machine information (triggering event, action 
taken, and variable status) is represented in the diagrams. 


In the .txt document, state machine diagrams depict only transition 
numbers. Following each diagram is a list of state transition 
descriptions. Complete transition details (triggering event, action 
taken, and variable status) are given in state transition tables in 
Appendix A. 


Please use the .pdf version whenever possible. It is the clearer 


representation of the state machine. In case of a difference between 
the two documents, please refer to the .pdf version. 
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6.1. Diagram Notations 
+-------------------------------- + 
| STATE 
+-------------- +----------------- + 

00000 
o N o Transition N 
00000 
v 
4+-------------------------------- + 
STATE | 
4+-------------------------------- + 


Figure 1: Diagram notations 


6.2. State Machine for GIST Querying Node 


The state machine diagram of the GIST querying node is below. 


Transition descriptions follow. 


Please refer to Appendix A.1 for complete transition details 
(triggering event, action taken, and variable status). 
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4+----------- + 00000 
| Any State +---------- o 180 
4+----------- + 00000 
| 
v 
E E EE EEE + + 
| IDLE | 
pr 5 + + 
nw nw nw 
| | | 
00000 00000 00000 00000 00000 | 
o 1 o o 2 0 +0 3 ot +o 4 ot +o 5 oł | 
00000 00000 | o0000 | | cooco | | 00000 | | 
| | | | I i | | 
v | | v | v | v | | 
Bo poo 4f---------- Hoi Poio + 
| Wait Response | | | 
o +--+ +++ ooo + | | 
| ^ | | | 
| | | | | 
00000 | 00000 00000 00000 
o 6 o | to 5 ot o 7.0 o 8 o 
00000 o0000 | 00000 00000 
| | | | | 
| | v v | 
| Y pm o ++ | 
| | | Wait MA Establishment | 
A ee Ho + 
| | | | 
| | | | 
| 00000 00000 00000 00000 00000 
| o 9 0 62. LAO +o 13 o+ o: 120 o 100 
| 00000 00000 | 00000 | da 00000 
v v v 
4f---------- Eo poo $ +--+ ++ 
| Established Downstream MRS 
A ne ner Bo Haro tiaió aa aes Pass eae sess ane + 
| El = | al e A 
00000 00000 00000 00000 00000 
+o 16 o+ +o 14 o+ +o 15 o+ +o 4 ot +o 17 o+ 
00000 00000 00000 00000 00000 


Figure 2: State Machine for GIST Querying Node 
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1**) An initial request from the NSLP application is received, which 
triggers Query messages requesting either D-mode or C-mode. 
Depending on the node’s local policy, the NSLP data might be 
piggybacked in the Query requesting D-mode. The Query may carry 
MAinfo if C-mode transport is needed. 


2) T_No_Response timer expires, and the maximum number of retries 
has been reached. The NSLP application is notified of the GIST 
peer discovery failure. 


3) T_No_Response timer expires. The Query is resent. 

4) A Data message is received. It is checked to see whether its 
sender matches the installed downstream peer info in the MRS; if 
so, it is processed. In WaitResponse state, this event might 


happen in the process of an MA upgrade, when the downstream peer 
is still not aware of establishment of the new MA. 


5) The NSLP application provides data for sending. NSLP data is 
queued because the downstream peer is not discovered or the 
required MA is still not established. 


6) A Response message is received. If a D-mode connection is 
requested or the available MA can be reused for the requested 
C-mode, the MRS is established. 


7*) Response message is received. If a C-mode connection must be 
established, and there is no available MA to be reused, MA 
establishment is initiated and the system waits for it to be 
completed. 


8) MA establishment fails. NSLP application is notified for 
unsuccessful message delivery. 


9) The NSLP application provides data for sending, and the 
requested transport parameters require an upgrade of the 
established MRS from D-mode/C-mode to C-mode. Or, the NSLP 
application notifies the GIST instance of the path change. As a 
result, downstream GIST peer discovery is initiated. 


10) The MRS lifetime expires or the NSLP application notifies that 
the MRS is no longer needed. The MRS is deleted. If not 
needed, the MA is deleted, too. The NSLP application is 
notified of the MRS change. 


11*) The path change is detected as a Response message from a new 


downstream GIST peer is received. A new MA must be established 
for the requested C-mode. 
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12*) A new MA is established. The MRS is installed. The queued NSLP 
data is sent. 

13)  T_Refresh_QNode timer expires. The Query message is sent. 

14) The NSLP application provides data for sending. It is sent via 
Data message towards the downstream GIST peer. 

15) The Response message from the downstream GIST peer is received. 
The peer is not changed. The MRS is refreshed (T_Refresh_QNode 
timer is restarted). 

16) The path change is detected as a Response message from a new 
downstream GIST peer is received. D-mode is requested, or the 
existing MA can be reused for the requested C-mode. 

17) The responding peer indicates that it has not received a Confirm 
message and it has no established upstream MRS. The Confirm 
message is resent. 

18) A general error or system-level error occurs. The MRS is 
deleted. If not needed, the MA is deleted, too. The NSLP 
application is notified of the MRS change. 

Remarks: 


*) 


Tsenov, 


Response and Confirm messages might be sent either in D-mode or 
C-mode, before or after MA establishment, depending on the node’s 
local three-way handshake policy and the availability of the MAs 
to be reused. See [1] for details. 


Depending on GIST local policy, NSLPdata might be sent as the 
payload of Query and Confirm messages (piggybacking). 
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6.3. State Machine for GIST Responding Node 


The GIST responding node state machine diagram is below. Transition 
descriptions follow. 


Please refer to Appendix A.2 for complete transition details 
(triggering event, action taken, and variable status). 


teSSSSsssssse + 00000 
| Any State +---------- o 140 
Ho + 00000 
v 
4$------------------ o + 
| IDLE | 
AO A O A + 
| A | ^ 
| | | | 
00000 | 00000 00000 00000 
o 1 0 | o 2.0 to 4 o+ o. 3 :0 
00000 | oo | 00000 | 00000 
v v 
| | 4+-------------------- Ho +---+ 
| | | Wait Confirm | 
| | dono +------------------— +----------- + 
| | | f | . 
| | | 
00000 00000 00000 00000 00000 
| +o 13 o+ o 8 o o. 5.0 OL <9 +o 6 ot 
| | oo000 | 00000 00000 00000 00000 
| | | | | | 
vo | v | v | 
+------ +------------- +------------------------ +------------------- + 
| Established Upstream MRS 
+------ +------------- +------------- +------------ +----------------- + 
| . ; —_ : 
| | | | | | | | 
| 00000 | | 00000 | | 00000 | | 00000 | 
to 9 oF to 11 o+ to 12 o+ to 10 o+ 
00000 00000 00000 00000 


Figure 3: State Machine for GIST Responding Node 


1) A Query message is received. The MRS is installed immediately 


because local policy permits it. The Query message might carry 
piggybacked NSLP data that will be provided to the NSLP 
application. 


Tsenov, et al. Informational [Page 16] 


RFC 5972 GIST State Machine October 2010 


2) 


10) 


11) 


A Query message is received. Local policy requires an explicit 
Confirm message for MRS installation. The Query message might 
carry piggybacked NSLP data that will be provided to the NSLP 
application. 


T_No_Confirm timer expires. Note that all cases of lost handshake 
GIST messages are handled only by the GIST querying node via 
resend of the Query message. 


A Query message is received again. This means that the sent 
Response message has not been received by the upstream GIST peer. 
The Response message is resent. 


A Confirm message is received that causes installation of the 
upstream MRS. 


In case of a lost Confirm message, data messages might be received 
from the upstream GIST node (it is unaware of the lost Confirm 
message). A Response message indicating the loss of the Confirm 
is sent back to the upstream GIST node. 


A Query message is received (from either an existing upstream GIST 
node or a new upstream GIST node) with a request to change the 
used GIST operation mode (from D-mode/C-mode to C-mode, if 
available; otherwise, it stays the same). Local policy requires 
an explicit Confirm message for MRS installation. 


The MRS lifetime expires or the NSLP application notifies that the 
MRS is no longer needed. The MRS is deleted. If used and not 
needed, the MA is deleted, too. The NSLP application is notified 
of the MRS change. 


The NSLP application provides data for sending. NSLP data is sent 
if the discovery process is successfully accomplished, or it is 
queued if a Confirm message is still expected to confirm 
establishment of an MA. 


A Query message is received. If it is sent from a new upstream 
GIST node, then there is a path change. Local policy does not 
need an explicit Confirm message for MRS installation. The MRS 
data is updated. 


A Query message is received with a request to change the used 
GIST operation mode (from D-mode/C-mode to C-mode, if available; 
otherwise, it stays the same). Local policy does not need an 
explicit Confirm message for MRS installation. The MRS data is 
updated. 
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9. 


9:3 


12) A Data message is received. Data messages are accepted only if 
the complete MRS is installed, e.g., the upstream peer info is 
installed. If not, then a Confirm message is expected and the 
Data message is not accepted. A Response message indicating the 
loss of the Confirm is sent back to the upstream GIST node. 


13) A Confirm message is received. It accomplishes assignment of an 
existing MA (or establishment of a new MA) needed for data 
transfer between peers. The information for the used MA is 
installed as the upstream peer info. 


14) A general error or system-level error occurs. The MRS is 
deleted. If not needed, the MA is deleted, too. The NSLP 
application is notified of the MRS change. 


Security Considerations 
This document does not raise new security considerations. Security 
considerations are addressed in the GIST specification [1] and in 
[6]. 
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Appendix A. 


A. 


Tsenov, 


I. 


GIST State Machine 


State Transition Tables 


October 2010 


The state transition tables below represent the state diagrams in 


ASCII format. 


Please use the 


.pdf version whenever possible. 
the clearer representation of the state machine. 


It is 


For each state there is a separate table that lists in each row: 
- an event that triggers a transition, 


- actions taken as a result of the incoming event, 
- and the new state at which the transitions ends. 


Please refer to the state machine diagram in Figure 2. 


State: IDLE 


+Transition 
| [Condition 


et al. 


State Transition Tables for GIST Querying Node 


|tx_Query 


[start T_No_Response 


[Queue NSLP data 


[Delete MRS 


TE 


(MA is used) 
((Delete MA) | | 


(Stop using shared MA) ) 
|Tg_NetworkNotification 


Informational 


|Wait 


Response 


IDLE 
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State: WaitResponse 


+Transition 

| [Condition |Action | State 
V--+------------------------ +------------------------- 4+----------- 
2) timeout T_No_Response) |tg_MessageStatus | IDLE 


( 
&& (MaxRetry) | 


| 
3) | (timeout T_No_Response) |Tx_Query |Wait 
| && (!MaxRetry) | restart T_No_Response [Response 
| | | 
4) |rx_ Data | IF (CheckPeerInfo) |Wait 
| | tg_RecvMsg to Appl. | Response 
5) oaei Queue NSLP data Wait 
| | |Response 
| | | 
6) |rx_Response) | | | Install MRS |Established 
| (rx_Response (MAinfo)&& |IF (RespCookie) |Downstream 
(MAexist)) tx_Confirm(RespCookie) | MRS 
tx_Data (Queued NSLP data) 
| | | 
7) |rx_ Response (MAinfo) && |tg_Establish_MA [Wait MA 
* | (!MAexist) | (tx_Confirm) |Establish. 
| | | 
as AA MRS) less 
| | IF (MA is used) | 
| | ((Delete MA) | | | 
| | (Stop using shared MA)) | 
| |Tg_NetworkNotification | 
| | | 
O AO O O O +----------- 


Tsenov, et al. Informational [Page 21] 


RFC 5972 GIST State Machine October 2010 


State: Established Downstream MRS 


+Transition 
| [Condition |Action | State 
V--+------------------------ +------------------------- 4+----------- 
4) |rx_Data | IF (CheckPeerInfo) |Established 
tg_RecvMsg to Appl. |Downstream 
| | ne 
| | 
9) | ((tg_SendMsg) && (C-mode) |tx_Query |Wait 
|&&(!MAexist) ) | | | Queue NSLP data |Response 
| (tg_MA_error) | | | | 
| (tg_InvalidRoutingState) | | 
seal pasad T_Inactive_ Delete MRS ie 
| QNode) ee (MA is used) 
| (tg_SetStateLifetime (0) ) | (Delete MA) | | 
| | (Stop using shared MA) | 
| |Tg_NetworkNotification | 
11) | (rx_Response (MAinfo) && p (Delete MA) | | Wait MA 
* | (NewPeer) &&(!MA_exist)) |(Stop using shared MA)) |Establish. 
| |tg_Establish_MA | 
| if (tx_Confirm) | 
13) |timeout T_Refresh_QNode |tx_Query Established 
Ea 
| | ian 
| 
14) |tg_SendMsg |tx_Data |Established 
| | restart T_Inactive_QNode |Downstream 
| | ie 
15) | (rx_Response) && |Refresh MRS |Established 
| (!NewPeer) |restart T_Inactive_QNode |Downstream 
| ' mes 
| 
16) | (rx_Response) | | ine (MA is used) Established 
(rx e a. ES (Delete MA) | | Downstream 
(MAexist) )) && (NewPeer) | (Stop using shared MA) |MRS 


| 

| |Install MRS | 
| |restart T_Inactive_QNode | 
| |IF (RespCookie) | 
| tx_Confirm(RespCookie) 
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17) |rx_Response (No_MRS_ 
installed) 


| 
18) | Tg_ERROR 
| 
| 
| 


State: Wait MA Establishment 


+Transition 

| [Condition 
Ve=tS=2==22H=2=2==32===3325=22=3= 
5) |tg_SendMsg 


8) |tg_MA_error 


12) |tg_MA_ Established 
* 
18) 


Tg_ERROR 


| 
| 
| 
| 
| 
+ 
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|tx_Confirm(RespCookie) |Established 


|tx_Data (Queued NSLP data) |Downstream 
ba 

| (Delete MRS) | IDLE 

|IF (MA is used) | 

| ((Delete MA) | | | 

| (Stop using shared MA)) | 
Tg_NetworkNotification 

AZ a Ho 
|Action | State 

AZ n rean $222 
|Queue NSLP data |Wait MA 

Establish. 

[Delete MRS | IDLE 
|tg_MessageStatus | 

| Install MRS |Established 
(tx_Confirm) Downstream 
tx_Data (Queued NSLP data) |MRS 

[Delete MRS | IDLE 

|IF (MA is used) | 

| ((Delete MA) | | | 

(Stop using shared MA) ) 

Tg_NetworkNotification 

AZ O Ho === 
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GIST State Machine 


A.2. State Transition Tables for GIST Responding Node 


Please refer to the state machine diagram in Figure 3. 


State: IDLE 


+Transition 
| [Condition 


1) |rx_Query&& 
IConfirmRequired) 


| ( 

| 
2) |rx_Query&é& 

| (ConfirmRequired) 
| 
| 


State: WAIT CONFIRM 


+Transition 
| [Condition 
Vira n Sees SSeS SSSSsee5 
3) |timeout T_No_Confirm 
4) |rx_Querys&& 
| (ConfirmRequired) 
| 
5) |rx_Confirm 
| 
| 
| 
6) rx_Data 


Tsenov, et al. 


|Action |State 
=-+ ——— — A A AA AAA + =-=- 
|tx_Response |Established 
| Install MRS [Upstream 
| IF (NSLPdata) |MRS 
| tg_RecvMsg (NSLPdata) | 
| to er 
|tx_Response |Wait 
|start T_No_Confirm |Confirm 
| IF (NSLPdata) | 
tg_RecvMsg (NSLPdata) | 
to Appl. 
=-+ ——— — — — AAA AAA + =-=- 
|Action | State 
=-+ =-= AAA + =- 
IDLE 
|tx_Response [Wait 
|start T_No_Confirm |Confirm 
| IF (NSLPdata) | 
tg_RecvMsg (NSLPdata) | 
| to a 
|Install Upstream MRS |Established 
| |Upstream 
| i 
tx_Response (No_MRS_ Wait 
installed) |Confirm 


Informational 


October 2010 
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14) | (Tg_ERROR) | | | (Delete MRS) | IDLE 
ae |IF (MA is used) 
((Delete MA) | | 


(Stop using shared MA) ) 
|Tg_NetworkNotification 


State: Established Upstream MRS 


(Stop using shared MA) 


+Transition 
| [Condition |Action |State 
vo-+------------------------ +------------------------- +----------- 
7) | (rx_Query) && [Delete MRS |Wait 
(ConfirmRequired) |tx_Response |Confirm 
|start T_No_Confirm 
|IF(MA is used) | 
(Delete MA) | | | 
(Stop using shared MA) | 
IF (NSLPdata) 
tg_RecvMsg (NSLPdata) | 
to Appl. | 
8) | (timeout T_Expire_RNode) |Delete MRS | IDLE 
| | tg_NetworkNotification 
k | 
(Delete MA) | | | 
| 
| 


| 
| 
| 
| 
| 
g_SetStateLifetime (0 pe (MA is used) 
| 
| 
| 
| 
| 
| 


9) |tg_SendMsg IF (!UpstreamPeerInfo) Established 
Queue NSLP data Upstream 
ELSE tx_Data MRS 
| 
10) |rx_Query IF (NewPeer) |Established 
Update UpstreamPeerInfo |Upstream 
|tx_Response | MRS 
restart T_Expire_RNode 
11) | rx_Query (MAinfo) && [Delete UpstreamPeerInfo |Established 
(!ConfirmRequired) [restart T_Expire_RNode |Upstream 
|tx_Response (MAinfo) |MRS 
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13) |rx_Confirm 


(Tg_ERROR) | | 
(Tg_MA_ Error) 


Tsenov, et al. I 


State Machine 


IF (UpstreamPeerInfo) |Established 


(tg_RecvMsg to Appl.) |Upstream 


| 
| 
&& (restart_T_Expire_ |MRS 

| RNode) 
| ELSE | 
| tx_Error (No_MRS_ | 
| A 
| 
Install UpstreamPeerInfo |Established 
tx_Data (queued_NSLP_data) |Upstream 
| [as 
| 
| (Delete MRS) | IDLE 
|IF (MA is used) | 
| ((Delete MA) | | | 

(Stop using shared | 
ce es 
| | 
4+------------------------- +----------- 
nformational 


October 2010 
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